🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/17075

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 7 New Failures, 3 Cancelled Jobs, 2 Unrelated Failures

As of commit e6fd05b with merge base f06a1f6 ():

This comment was automatically generated by Dr. CI and updates every 15 minutes.

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

Hi, this PR needs major changes I'm afraid.

1. The changes to fold_qdq_with_annotated_qparams_pass and propagate_qparams_pass are very likely not needed, rather they are masking a faulty implementation either of the add_mm or the integration in the aot_arm_compiler.
2. The addition of the add_mm is a significant change which should be made in a separate PR properly tested with unittests as is done with all other ops.
3. It would be great to add mv2 also as a pytest similar to mv3, in fact I would suggesting starting to get that working before adding support to the aot_arm_compiler since the compilation pipeline is guaranteed to be working there.

Sure - I agree with the approach. I just wanted to share the work I've been up to recently so
that we can have exactly this kind of discussion.

Context on the design choice:

The Cortex-M backend keeps addmm directly (vs ARM's decomposition to Conv2D) to leverage CMSIS-NN's optimized linear
kernels. This creates a qparam propagation challenge:

When PyTorch decomposes nn.Linear to edge dialect:
linear(input, weight, bias) → addmm(bias, input, weight.T)

The weight flows through a transpose before reaching addmm:
weight → permute_copy → addmm

FoldAndAnnotateQParamsPass folds the DQ into permute, but output_qparams remains empty (no Q node after permute).
The addmm node expects weight qparams at input_qparams[2], hence PropagateQParamsPass bridges this gap.

Proposed approach:

1. I'll first add test_addmm.py and test_mobilenet_v2.py unit tests following the existing patterns
2. Once those pass and validate the pipeline, we can review whether PropagateQParamsPass is the right solution or if
   there's a cleaner approach
3. The aot_arm_compiler integration can follow in a subsequent PR

This way we have proper test coverage before discussing the implementation details. Let me get the unit tests
working first.

Sounds good!

When PyTorch decomposes nn.Linear to edge dialect:
linear(input, weight, bias) → addmm(bias, input, weight.T)

The weight flows through a transpose before reaching addmm:
weight → permute_copy → addmm

I think the issue here is that you are not using the EdgeCompileConfig used in the tester:

 config = EdgeCompileConfig(
            preserve_ops=[
                torch.ops.aten.linear.default,
                torch.ops.aten.hardsigmoid.default,
                torch.ops.aten.hardsigmoid_.default,
                torch.ops.aten.hardswish.default,
                torch.ops.aten.hardswish_.default,
            ],
            _check_ir_validity=False,
            _core_aten_ops_exception_list=[torch.ops.aten.max_pool2d.default],
        ) 

When linear is not decomposed you avoid the issues around q/dq folding. In general the design philosophy is that we want to make the decompositions and annotations to get correct q/dq values directly rather than handling special cases in the folding, as that gets complex very quickly from our previous experience in the arm backend.